Subject: ATM Encapsulation for APPN-HPR

From: "jim (j.) cobban" <[email-masked]>
Date: Fri, 12 Apr 1996 15:55:00 -0400

I noticed a couple of typos, in particular the wrong NLPID in A.5-8, and the
last two paragraphs of the proposal out of order.

This message proposes amended text for the HPR Extensions for ATM Networks
draft (ATM-03) to modify the specification of Logical Data Link Control.
This is based upon the discussion at AIW 10.  The principle purposes of these
amendments are:

  1) facilitate interworking between ATM and other media by supporting
     service interworking, particularly with frame-relay and LANs.
  2) support multiplexing of HPR connections over a single ATM VCC which
     simplifies the implementation of LAN interworking units, and provides a
     tool which customers can use to manage their public network costs.
  3) facilitate the deployment of the new light-weight logical data link
     control (LDLC) on media other than ATM by providing a migration
     mechanism.

Section 1.2.3 "Native ATM DLC" is moved before section 1.2.2 because it
introduces the LDLC concept which is then referenced in "Frame Relay
Interworking".  Since the contentious issues are now defused, this ordering
of the sections is more logical.  However although LDLC is being introduced
for ATM, and will first be deployed in ATM, a major thrust is that LDLC is
the optimal link control layer for HPR over any medium as long as the RTP and
CF over RTP option sets are implemented.  I therefore propose the following
amendments of section 1.2.3 (which is now section 1.2.2).

Add to the end of the second paragraph the sentence "This new LDLC may also
be used on any medium which supports IEEE 802.2 LLC 1, including LANs and
Frame-Relay."

The last two sentences in the third paragraph ("Additional architecture ...
providing error recovery must be specified.") should be replaced by "Support
of these link connections on ATM is specified by existing industry agreements
based upon RFC 1483, and utilizes IEEE 802.2 LLC 2 to provide error
recovery."

Section 1.2.2 "Frame Relay Interworking" is moved after section 1.2.3, which
introduces the LDLC concept, and modified as follows:

In the third paragraph the last word, "doubtful", is replaced by "outside the
scope of this specification".

The remaining two paragraphs in this section are replaced as follows:

"Although the HPR frame-relay encapsulation, based upon RFC 1490, and the HPR
ATM encapsulation, based upon RFC1483, are aligned, it should be understood
that service interworking cannot be used between an HPR node implementing the
base ATM DLC described in this paper, and an HPR node implementing the base
frame-relay DLC described in the HPR specification.  That is because base ATM
DLC support uses Logical Data Link Control (LDLC) while base frame-relay
support uses IEEE 802.2 LLC2.  The two nodes would perform XID negotiation,
discover that they have no shared DLC capability, and the two nodes would
reject the link connection with a CV 22 indicating the invalid value of the
link support bits in the CV 61.  However if either the ATM node implements
LLC2 as an option, or the frame-relay node supports LDLC as an option, then
service interworking is supported."

A new section 1.2.4 "LAN Interworking" is added after section 1.2.3.

"Existing implementations of HPR on LANs use IEEE 802.2 LLC2 to provide
reliable delivery of XIDs, determination of when the link is available,
deactivation of the link, and link availability idle probing.  Since base
level HPR nodes on ATM use LDLC for these functions service level
interworking does not work in this case.  The two nodes would perform XID
negotiation, discover that they have no shared DLC capability, and the two
nodes would reject the link connection with a CV 22 indicating the invalid
value of the link support bits in the CV 61.  However if either the ATM node
implements LLC2 as an option, or the LAN based node supports LDLC as an
option, then service interworking is supported."

A new section 1.2.5 "X.25 Interworking" is added.

"Exising implementations of HPR on LANs use Qualified Logical Link Control to
provide reliable delivery of XIDs, determination of when the link is
available, and deactivation of the link.  Since base level HPR nodes on ATM
use LDLC for these functions service level interworking does not work in this
case.  The two nodes would perform XID negotiation, discover that they have
no shared DLC capability, and the two nodes would reject the link connection
with a CV 22 indicating the invalid value of the link support bits in the CV
61.  However if either the ATM node implements LLC2 as an option, or the X.25
based node supports LDLC as an option, then service interworking is
supported.

"An X.25 implementation of LDLC does not use the Q-SM, Q-DISC, Q-UA, Q-DM,
Q-FRMR, or Q-RR control packets.  Instead the link initialization is
signalled by transporting the LDLC NLPs for XID_DONE and DEACT as unqualified
data packets.  Q-XID is retained for XID negotiation.  Q-TEST is not sent,
but is responded to if received."

Section 2.1 is modified to omit the restriction of 1 LDLC per virtual
channel because SAP multiplexing is now supported.

Section 2.4 is modified as follows:

The text under the third bullet is modified to:

"This function enables HPR to signal an adjacent node when a link connection
is no longer required."

A fourth and fifth bullet are added:

"o  Optionally support SAP multiplexing

   "Multiple LDLC connections can share a single ATM virtual channel, or
    frame-relay virtual circuit, or pair of MAC addresses on a LAN, through
    the use of the SAPs to identify individual connections.

"o  Optionally support idle probing

   "If the underlying transport does not guarantee notification of the loss
    of a connection, or if multiple link transmission groups are used then an
    idle probe mechanism is supported to detect the loss of a link."

The last paragraph ("LDLC should be used ...") is strengthened:

"LDLC should be supported on all HPR link types by nodes which
support the CF over RTP tower."

In section 2.4.2 the introduction of the ability to negotiate to either LLC2
or LDLC requires some amendment of the protocol boundaries diagram.  I
propose:

		       +------------------------+    +------------------+
		       |			|    |			|
		       |	CS		|    |       NCL        |
		       |			|    |			|
		       +------------------------+    +------------------+
			  ^				^	^
			  | MU_XID			|	|
			  | SET_MODE			|	|
			  | DISC			|	|
			  v				|	|
		       +------------------------+	|	|
		       |	convergence	|	| NLP	| NLP(data)
		       +------------------------+	| (data)|
			 ^                   ^		|	|
			 | XID               | SET_MODE	|	|
			 | XID_DONE          | DISC	|	|
			 | DEACT             | INOP	|	|
			 | INOP              |		|	|
			 v                   v          v	|
+------------+         +----------------+ +----------------+	|
|    ATM     |  INOP   |		| |		   |	|
| Signalling |-------->|      LDLC	| |	LLC2       |	|
|            |         |		| |		   |	|
+------------+         +----------------+ +----------------+	|
			  ^			^		|
			  | XID			|		|
			  | TEST		| I frm		|
			  | NLP(LDLC)		| S frm		|
			  |  XID_DONE_(RQ|RSP)	|		|
			  |  DEACT_(RQ_RSP)	|		|
			  |			|		|
			  v			v		v
		       +------------------------------------------------+
		       |						|
		       |		RFC 1483 (LLC1)			|
		       |						|
		       +------------------------------------------------+

Also the definition of NLP(LDLC) at the bottom of this figure should have
XID_RQ and XID_RSP removed.

The text in section 2.4.3 should be modified to remove most, if not all,
occurrences of "ATM".  This is because LDLC is now applicable to all media.

A new section 2.4.3.2, after "General Description" and before "Example
sequences" is added "XID Negotiation"

"Base link support for an ATM HPR station is for support of LDLC only.  This
is signalled in the XID CV 61 as described in appendix D.2.2.2 "HPR
capabillities control vector (CV 61)".  However for
support of service interworking with existing stations attached through
Frame-Relay or on LANs, and for migration of existing LLC2 based
implementations of HPR on other medi to LDLC this specification describes a
mechanism for negotiating toward support of LDLC or LLC2 for a particular HPR
connection.

"The CV 61 can indicate one of the following levels of DLC support:

 "o support for ERP only.  That is NLPs are transported in I frames or the
    equivalent.
 "o ERP is not supported.  That is NLPs are transported in UI frames, or
    equivalent, however LLC2 is still used to detect loss of the link.
 "o both ERP and non-ERP transport support, but non_ERP is preferred.
 "o only LDLC is supported.  That is link activation and deactivation are
    performed using NLPs, and NLPs are transported in UI frames, or 
    equivalent.  On VC based services, such as ATM and Frame-Relay, no
    idle probing to detect loss of the link is required because the
    underlying network will report such a loss, however a mechanism, using
    TEST frames is available for link idle probing to support LAN media.
 "o LDLC is preferred, but ERP support is available.
 "o LDLC is preferred, but non-ERP support is available.
 "o LDLC is preferred, but both ERP and non-ERP support are also available.

"If both link stations indicate that they support LDLC then LDLC is used, as
described in this section.

"If either of the link stations does not support LDLC then link support is
negotiated as described in the base HPR architecture.

"If an LDLC only node receives an XID which does not indicate support for
LDLC it sends an XID containing CV 22 with sense code X'10160029?' - LDLC not
supported.

"Since an LDLC only node sends an XID in which the CV 61 indicates that it
does not support either ERP or non-ERP, this XID will be rejected by a node
which does not support LDLC by sending an XID containing CV 22 with sense
code X'10160028' - invalid error recovery mode specified, as indicated by the
base HPR specification.

Appendix A is extensively modified.  I propose using the same syntax as is
used in the main HPR specification for the various encapsulations.

"A.1 ATM format for exchange of XID

"The XID_RQ and XID_RSP LDLC signals are carried in this format as XID
frames. 

"----------------------------------------------------------------------
"Byte       Content
"----------------------------------------------------------------------
" 0         destination SAP X'FE' indicating use of NLPID protocol
            identification
" 1         source SAP X'FE' indicating use of NLPID protocol
            identification
" 2         Command Code X'03', Unnumbered Information with P/F bit off.
" 3         Network Layer Protocol Identifier X'09', indicating use of
	    Q.9321 layer 2 and layer 3 protocol identification elements
" 4-5       layer 2 protocol identifier X'4C80' indicating use of IEEE 802.2
	    LLC
" 6-7       layer 3 protocol identifier X'7083' indicating APPN/ISR
" 8         SAP multiplexing destination SAP, normally X'04'
" 9         SAP multiplexing source SAP, normally X'04'
"10         Command Code X'BF', eXchange IDentification with P/F bit on.
"11-n	    information field of XID

"A.2 ATM format for exchange of NLPs in UI frames

"The UI frame is used to carry Network
Layer Packets (NLPs) and LDLC signals if SAP multiplexing is explicitly
requested by the presence of a subfield 80 in the CV 61 of the XIDs sent
from both ends in the preceding XID negotiation.  Otherwise the NULL layer 2
is used, as shown in section A.3.

"----------------------------------------------------------------------
"Byte       Content
"----------------------------------------------------------------------
" 0         destination SAP X'FE' indicating use of NLPID protocol
            identification
" 1         source SAP X'FE' indicating use of NLPID protocol
            identification
" 2         Command Code X'03', Unnumbered Information with P/F bit off.
" 3         Network Layer Protocol Identifier X'09', indicating use of
	    Q.9321 layer 2 and layer 3 protocol identification elements
" 4-5       layer 2 protocol identifier X'4C80' indicating use of IEEE 802.2
	    LLC
" 6-7       layer 3 protocol identifier X'7085' indicating APPN/HPR
" 8         SAP multiplexing destination SAP, as determined by the value
	    of SF 80 in CV 61 in the XIDs sent by the destination.
" 9         SAP multiplexing source SAP, as determined by the value of SF 80
	    in CV 61 in the XIDs sent by the source.
"10         Command Code X'BF', eXchange IDentification with P/F bit on.
"11-n	    information field of XID

"A.3 ATM format for exchange of NLPs over Null Layer 2

"The Null layer 2 is used to carry Network
Layer Packets (NLPs) and LDLC signals if SAP multiplexing is not
requested by the presence of a subfield 80 in the CV 61 of the XIDs sent
from both ends in the preceding XID negotiation.  Otherwise the UI layer 2
is used, as shown in section A.2.

"----------------------------------------------------------------------
"Byte       Content
"----------------------------------------------------------------------
" 0         destination SAP X'FE' indicating use of NLPID protocol
            identification
" 1         source SAP X'FE' indicating use of NLPID protocol
            identification
" 2         Command Code X'03', Unnumbered Information with P/F bit off.
" 3         Network Layer Protocol Identifier X'09', indicating use of
	    Q.9321 layer 2 and layer 3 protocol identification elements
" 4-5       layer 2 protocol identifier X'5081' indicating absence of
	    layer 2.
" 6-7       layer 3 protocol identifier X'7085' indicating APPN/HPR
" 8-n	    NLP.

"A.4 ATM format for exchange of TEST

"The TEST frame is supported for idle probing, which is only required
on multiple link transmission groups or on media which does not explicitly
signal loss of connection to the higher layers.  The ability to transmit
TEST frames is optional on ATM because the loss of a virtual channel
connection is signalled to the higher layers, however responding to a TEST
frame which is received is mandatory.

"----------------------------------------------------------------------
"Byte       Content
"----------------------------------------------------------------------
" 0         destination SAP X'FE' indicating use of NLPID protocol
            identification
" 1         source SAP X'FE' indicating use of NLPID protocol
            identification
" 2         Command Code X'03', Unnumbered Information with P/F bit off.
" 3         Network Layer Protocol Identifier X'09', indicating use of
	    Q.9321 layer 2 and layer 3 protocol identification elements
" 4-5       layer 2 protocol identifier X'4C80' indicating use of IEEE 802.2
	    LLC
" 6-7       layer 3 protocol identifier X'7085' indicating APPN/HPR
" 8         SAP multiplexing destination SAP, normally X'04'
" 9         SAP multiplexing source SAP, normally X'04'
"10         Command Code X'F3', Test with P/F bit on.
"11-n	    information field of Test

"A.5 Frame-Relay format for exchange of XID

"The XID_RQ and XID_RSP LDLC signals are carried in this format as XID
frames. 

"----------------------------------------------------------------------
"Byte       Content
"----------------------------------------------------------------------
" 0-1       Q.922 address
" 2         Command Code X'03', Unnumbered Information with P/F bit off.
" 3         Network Layer Protocol Identifier X'08', indicating use of
	    Q.933 layer 2 and layer 3 protocol identification elements
" 4-5       layer 2 protocol identifier X'4C80' indicating use of IEEE 802.2
	    LLC
" 6-7       layer 3 protocol identifier X'7083' indicating APPN/ISR
" 8         SAP multiplexing destination SAP, normally X'04'
" 9         SAP multiplexing source SAP, normally X'04'
"10         Command Code X'BF', eXchange IDentification with P/F bit on.
"11-n	    information field of XID

"A.6 Frame-Relay format for exchange of NLPs in UI frames

"The UI frame is used to carry Network
Layer Packets (NLPs) and LDLC signals if SAP multiplexing is explicitly
requested by the presence of a subfield 80 in the CV 61 of the XIDs sent
from both ends in the preceding XID negotiation.  Otherwise the NULL layer 2
is used, as shown in section A.7.

"----------------------------------------------------------------------
"Byte       Content
"----------------------------------------------------------------------
" 0-1       Q.922 address
" 2         Command Code X'03', Unnumbered Information with P/F bit off.
" 3         Network Layer Protocol Identifier X'08', indicating use of
	    Q.933 layer 2 and layer 3 protocol identification elements
" 4-5       layer 2 protocol identifier X'4C80' indicating use of IEEE 802.2
	    LLC
" 6-7       layer 3 protocol identifier X'7085' indicating APPN/HPR
" 8         SAP multiplexing destination SAP, as determined by the value
	    of SF 80 in CV 61 in the XIDs sent by the destination.
" 9         SAP multiplexing source SAP, as determined by the value of SF 80
	    in CV 61 in the XIDs sent by the source.
"10         Command Code X'03', Unnumbered Information with P/F bit off.
"11-n	    NLP or LDLC signal

"A.7 Frame-Relay format for exchange of NLPs over Null Layer 2

"The Null layer 2 is used to carry Network
Layer Packets (NLPs) and LDLC signals if SAP multiplexing is not
requested by the presence of a subfield 80 in the CV 61 of the XIDs sent
from both ends in the preceding XID negotiation.  Otherwise the UI layer 2
is used, as shown in section A.2.

"----------------------------------------------------------------------
"Byte       Content
"----------------------------------------------------------------------
" 0-1       Q.922 address
" 2         Command Code X'03', Unnumbered Information with P/F bit off.
" 3         Network Layer Protocol Identifier X'08', indicating use of
	    Q.933 layer 2 and layer 3 protocol identification elements
" 4-5       layer 2 protocol identifier X'5081' indicating absence of
	    layer 2.
" 6-7       layer 3 protocol identifier X'7085' indicating APPN/HPR
" 8-n	    NLP.

"A.8 Frame-Relay format for exchange of TEST

"The TEST frame is supported for idle probing, which is only required
on multiple link transmission groups or on media which does not explicitly
signal loss of connection to the higher layers.  The ability to transmit
TEST frames is optional on Frame-Relay because loss of a virtual circuit
connection is signalled to the higher layers through the LMI, however
responding to a TEST frame which is received is mandatory.

"----------------------------------------------------------------------
"Byte       Content
"----------------------------------------------------------------------
" 0-1       Q.922 address
" 2         Command Code X'03', Unnumbered Information with P/F bit off.
" 3         Network Layer Protocol Identifier X'08', indicating use of
	    Q.933 layer 2 and layer 3 protocol identification elements
" 4-5       layer 2 protocol identifier X'4C80' indicating use of IEEE 802.2
	    LLC
" 6-7       layer 3 protocol identifier X'7085' indicating APPN/HPR
" 8         SAP multiplexing destination SAP, normally X'04'
" 9         SAP multiplexing source SAP, normally X'04'
"10         Command Code X'F3', Test with P/F bit on.
"11-n	    information field of Test

"A.9 LAN format for exchange of XID

"The XID_RQ and XID_RSP LDLC signals are carried in this format as XID
frames. 

"----------------------------------------------------------------------
"Byte       Content
"----------------------------------------------------------------------
" 0         SAP multiplexing destination SAP, normally X'04'
" 1         SAP multiplexing source SAP, normally X'04'
" 2         Command Code X'BF', eXchange IDentification with P/F bit on.
" 3-n	    information field of XID

"A.10 LAN format for exchange of NLPs in UI frames

"The UI frame is used to carry Network Layer Packets (NLPs) and LDLC signals.

"----------------------------------------------------------------------
"Byte       Content
"----------------------------------------------------------------------
" 0         destination SAP, as determined by the value
	    of SF 80 in CV 61 in the XIDs sent by the destination.
" 1         source SAP, as determined by the value of SF 80
	    in CV 61 in the XIDs sent by the source.
" 2         Command Code X'03', Unnumbered Information with P/F bit off.
" 3-n	    NLP or LDLC signal

"A.11 LAN format for exchange of TEST

"The TEST frame is supported for idle probing. Idle probing is required
on LAN media because it does not explicitly signal loss of connection to the
higher layers.  The ability to transmit and respond to TEST frames is
required on LAN media.

"----------------------------------------------------------------------
"Byte       Content
"----------------------------------------------------------------------
" 0         destination SAP, normally X'04'
" 1         source SAP, normally X'04'
" 2         Command Code X'F3', Test with P/F bit on.
" 3-n	    information field of Test

"A.12 X,25 format for exchange of XID

"The XID_RQ and XID_RSP LDLC signals are carried in qualified data packets
as Q-XID commands or responses.

"----------------------------------------------------------------------
"Byte       Content
"----------------------------------------------------------------------
" 0         command/response indicator.  X'FF' indicates a command, any
	    other value indicates a response.
" 1         Command Code X'BF', eXchange IDentification with P/F bit on.
" 2-n	    information field of XID

"A.13 X,25 format for exchange of NLPs 

"Unqualified data packets are used to carry Network Layer Packets (NLPs) and
LDLC signals.

"----------------------------------------------------------------------
"Byte       Content
"----------------------------------------------------------------------
" 0-n	    NLP or LDLC signal

"A.14 X,25 format for exchange of TEST

"TEST frames are carried as Q-TEST control packets in a data packet with
the Q bit set.  The Q-TEST packet is supported for idle probing. Idle probing
is not required on X,25 media because X.25 explicitly signals loss of
connection to the higher layers.  The ability to transmit  Q-TEST packet is
optional.  The ability to respond to Q-TEST packets is required on X,25 media.

"----------------------------------------------------------------------
"Byte       Content
"----------------------------------------------------------------------
" 0         command/response indicator.  X'FF' indicates a command, any
	    other value indicates a response.
" 1         Command Code X'F3', Test with P/F bit on.
" 2-n	    information field of Test

"A.15 LDLC Header Format

The text from existing section A.1.1 is retained except that the last
sentence becomes "The LDLC NLP contains no data field." because this format
is no longer used for XIDs.

In the table A.1.1.1.1 (which is now A.12.1.1 I guess) the first two entries
are retired.  The remaining code points remain the same.

In appendix C the code point in the switching mode field for function routing
is amended to 101, and therefore moved in front of the ANR entry, to avoid a
potential conflict with the subarea TG sweep command.  The text on byte 1
bits 0-3 is also amended to refer to the bit value 101.  Also the text on
page C-3 which describes the Function Routing field is amended to refer to
the bit value 101.

In appendix D a new section D.2.2.2 is added to amend the description of the
HPR capabilities control vector (CV 61).  The change to this vector is:

"----------------------------------------------------------------------
"Byte    Bit     Content
"----------------------------------------------------------------------

" 2      0-1     11    The sender supports neither ERP or non-ERP support.
		       This value is only valid if the sender also sets
		       bit 4 (LDLC supported).  If this value is received by
		       a station which does not support LDLC, or if bit 4 is
		       not also set, then the XID is
		       failed by sending a CV 22 with sense code X'10160028'
		       - invalid error recovery mode specified.

"        4       Logical Data Link Control (LDLC) support indicator
		 0     This node does not support LDLC.  If this value is
		       received by a node which only supports LDLC then the
		       XID is failed by sending a CV 22 with sense code
		       X'10160029?' - LDLC not supported.

		 1     This node does support LDLC

In appendix E a new section E.3 "Request Error" is added, which contains the
description of sense code 1016 with the addition of subcode 0029? - LDLC not
supported.